This prevents multiple queries and large amounts of data being transferred between being the client and server. The large amounts of data being transferred messes with the performance characteristics this is meant to provide.

NOTE: This change fundamentally changes how buckets work!

• The "Index" column dropped and now requires a DateTime-based property defined and referenced in the BucketOptionsAttribute
• Buckets no longer have a change tracker. Buckets can be added to or they can be removed by their group

The "Index" column change was fundamentally required to keep bucket ordering without fetching the last index from the DB. For the most part, interacting with buckets generated by the old process should still work - your data would still be there. Where there would be complete incompatibility is whether your sub-entity actually has a DateTime property as that is unfortunately the only way this works. This new process follows the documentation here: https://www.mongodb.com/blog/post/time-series-data-and-mongodb-part-2-schema-design-best-practices

The "buckets no longer have a change tracker" is mostly related to switching to command staging rather than an entity collection. Additionally however, buckets aren't designed for editing existing data or removing individual items - it is designed for mass storage of small pieces of data. With the EntityBucketStagingCollection being redundant, having a collection at all (and thus a change tracker) was pointless.

If this change breaks your workflow - I recommend manually bringing in the removed EntityBucketStagingCollection and creating your own version of the MongoDbBucketSet. Yes that sucks though breaking changes like this can happen from time-to-time prior to v1.0.0 - the majority of the time however, I endeavour to avoid breaking changes for common use cases.